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(57) ABSTRACT 

Methods and techniques for selective service access are 
described, A short range, wireless device establishes lists of 
available devices within its transmitting proximity that are 
able to provide a desired service. The lists can be ranked 
based upon a service profile, e.g., established by the device 
user. The lists can also be periodically updated to accom- 
modate device mobility. 
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METHOD AND APPARATUS FOR SELECTIVE 
SERVICE ACCESS 

BACKGROUND 

[0001] The present invention relates to telecommunica- 
tions and data communications, and more particularly to a 
method and apparatus for providing devices, e.g., short- 
range wireless devices, with selective service access (e.g., 
Internet service) by selecting from among one or more 
network devices that offer a desired service. 

[0002] The radiocommunication industry has made phe- 
nomenal strides in commercial operations in the United 
States as well as the rest of the world. For example, the 
growth of cellular communication systems in major metro- 
politan areas has far exceeded expectations and is rapidly 
outstripping system capacity. If this trend continues, the 
effects of this industry's growth will soon reach even the 
smallest markets. At the same time, the commercial success 
of hand-held information processing devices, e.g., personal 
digital assistants (PDAs), and the Internet has resulted in a 
confluence of information and communication technologies 
that, in turn, is generating new products and a consumer 
demand for new services. 

[0003] It is widely anticipated that users of hand-held 
information processing devices will soon generally expect to 
receive a wide range of services via a single hand-held 
device, e.g., telephone services, Internet access and access to 
any other available information network. An example which 
is sometimes used in describing the future of these types of 
devices and services is that of a person moving about in a 
shopping mall being able to receive and/or query local 
information networks regarding sales, products, etc. using 
his or her hand-held device. Wireless technologies offer a 
mechanism for providing such services. One such technol- 
ogy, commonly referred to as Bluetooth, provides short- 
range, point-to-point radio access for communication 
between devices. When a Bluetooth device (referred to 
herein as the initiator), e.g., a hand-held device, wants to 
identify other Bluetooth devices that are in the vicinity, e.g., 
those associated with a number of different shops in the 
mall, it sends an inquiry message. All Bluetooth devices 
within range of the initiator that are set in discoverable mode 
will answer the inquiry. The initiator can then decide 
whether it wants to connect to any of the discovered devices. 
If the initiator is searching for other devices because it wants 
to make use of a specific service (presumably because the 
user requested that service or because an apphcation running 
on the user's hand-held device requires that service), the 
inquiry message can contain a class of, device identifier, so 
that only devices which belong to that class will answer the 
inquiry. This shall at least increase the possibility that the 
device that the initiator chooses to connect to can offer the 
requested service. 

[0004] Once two Bluetooth devices are connected, the 
Bluetooth Service Discovery Protocol (SDP) can be used to 
obtain more detailed information about available services. 
This protocol is described in more detail below. Briefly, 
however, the Bluetooth device that wants to use a particular 
service sends an SDP request, specifying the service that it 
is seeking. If a peer Bluetooth device can offer the requested 
service, it sends an SDP reply with an identifier for that 
service. The SDP requests can also include a list of 



attributes, in which case the SDP reply contains the values 
of those attributes for this specific service. 

[0005] When a Bluetooth device receives several answers 
to an inquiry, a selection is required to determine the 
answering device to which a connection should be made. 
Since the Bluetooth device may be mobile, this selection 
process is further complicated by that possibility that, even 
after the initial selection of a device offering the desired 
service, an even more suitable candidate device may come 
into range. One way to select among the answering devices 
is to present all of the answering devices to the user, e.g., on 
a display of the user's Bluetooth device, and let the user 
decide which one to connect to. This manual selection 
process may prove to be time-consuming and annoying, 
particularly if there are a large number of answering devices 
that provide the desired service within range of the user's 
Bluetooth device. 

[0006] Accordingly, it would be desirable to provide 
methcxls and systems for automating the selection of ser- 
vices. 

SUMMARY 

[0007] According to exemplary embodiments of the 
present invention, these and other drawbacks, limitations 
and problems associated with conventional service selection 
techniques are overcome. Exemplary embodiments of the 
present invention provide an initiator with a service profile 
which can be compared with the relevant service attributes 
from responding Bluetooth devices. The initiator can main- 
tain a device list of proximate Bluetooth devices, as well as 
a candidate list which is ordered based on how well the 
proximate Bluetooth devices match the service profile. The 
candidate list can be used to select a servicing device when 
the service associated with that list is needed, e.g., by an 
application running on the initiator. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0008] The objects and advantages of the invention will be 
understood by reading the following detailed description in 
conjunction with the drawings, in which: 

[0009] FIG. 1 illustrates a Bluetooth piconet; 

[0010] FIG. 2 illustrates a larger piconet, including a 
master and several slaves; 

[0011] FIG. 3 illustrates an exemplary scattemet; 

[0012] FIG. 4 illustrates an INQUIRY message packet; 

[0013] FIG. 5 illustrates the signaling performed between 
two Bluetooth units for neighbor discovery and connection 
establishment; 

[0014] FIG. 6 illustrates an INQUIRY RESPONSE mes- 
sage packet; 

[0015] FIG. 7 is a flowchart illustrating exemplary steps 
for maintaining device lists according to an exemplary 
embodiment of the present invention; and 

[0016] FIGS. 8(fl) and S(b) depict signalUng for a search 
process according to an exemplary embodiment of the 
present invention. 
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DETAILED DESCRIPTION 

[0017] The various features of the invention will now be 
described with reference to the figures, in which like parts 
are identified with the same reference characters. In the 
following description, for purposes of explanation and not 
limitation, specific details are set forth, such as particular 
circuits, circuit components, techniques, etc. in order to 
provide a thorough understanding of the present invention. 
However, it will be apparent to one skilled in the art that the 
present invention may be practiced in other embodiments 
that depart from these specific details. In other instances, 
detailed descriptions of well-known methods, devices, and 
circuits are omitted so as not to obscure the description of 
the present invention. 

[0018] Conventional networking protocols are based on 
the characteristics and/or features of fixed networks. In fixed 
networks, the network configuration typically does not 
change. Although nodes can be added and removed in fixed 
networks, the route traveled by data packets between two 
nodes typically does not change. The disadvantage is that 
fixed networks cannot be easily reconfigured to account for 
increases in data traflBc, also called system loading. Accord- 
ingly, when system loading increases for one node, the 
surrounding nodes are likely to experience increased delays 
in the transmission and reception of data. Another drawback 
to fixed networks is that they are not well-suited to node 
mobility and, therefore, do not readily support the types of 
mobile services described above. 

[0019] In contrast to fixed networks, ad hoc networks are 
dynamic. An ad hoc network is formed when a number of 
nodes decide to join together to form a network. Since nodes 
in ad hoc networks operate as both hosts and routers, ad hoc 
networks do not require the infirastrucmre required by fixed 
networks. Accordingly, ad hoc networking protocols are 
based upon the assumption that nodes may not always be 
located at the same physical location. One example of a 
technology which enables the development of short range, 
wireless, ad hoc networks is that defined by the recently 
developed Bluetooth technology which facilitates two-way 
data transmission. Bluetooth is a universal radio interface in 
the 2.45 GHz frequency band that enables portable elec- 
tronic devices to connect and communicate wirelessly via 
short-range, ad hoc networks. Readers interested in various 
details regarding the Bluetooth technology are referred to 
the article entitled "BLUETOOTH — ^The universal radio 
interface for ad hoc, wireless connectivity"* authored by Jaap 
Haartsen and found in the Ericsson Review, Telecommuni- 
cations Technology Journal No. 3, 1998, the disclosure of 
which is incorporated here by reference. For the purposes of 
the present invention, only Bluetooth features of immediate 
interest are described here to avoid obscuring these exem- 
plary embodiments. 

[0020] To provide some context within which to under- 
stand selective service access systems and methods accord- 
ing to the present invention, some exemplary ad hoc network 
topologies which operate using Bluetooth technology will 
first be described. Those skilled in the art will, however, 
appreciate that the present invention can be implemented in 
other networks than those described here. 

[0021] FIG. 1 illustrates a Bluetooth piconet. A piconet is 
a collection of digital devices, such as any of those men- 
tioned above, connected using Bluetooth technology in an 



ad hoc fashion. A piconet is initially formed with two 
connected Bluetooth devices. In each piconet, for example 
piconet 100, there exists one master Bluetooth imit and one 
or more slave Bluetooth units. In FIG. 1 Bluetooth unit 101 
is a master unit and unit 102 is a Bluetooth slave unit, 

[0022] FIG. 2 illustrates a larger piconet, including a 
master and several slaves. According to Bluetooth technol- 
ogy a slave unit can only communicate directly with a 
master unit. FIG. 2 illustrates a piconet 200 with a master 
unit 201 and a plurality of slave units 202-208 arranged in 
a star network topology. If slave unit 202 wishes to com- 
municate with slave unit 206, slave unit 202 would transmit 
the information it wished to communicate to master unit 
201. Master unit 201 would then transmit the information to 
slave unit 206. 

[0023] As those skilled in the art will appreciate, the 
topologies which develop can become quite complex as the 
number of devices in the vicinity of one another increases. 
For example, FIG. 3 illustrates an exemplary scatternet 300. 
A scatternet is formed by multiple independent and unsyn- 
chronized piconets. In FIG. 3, piconet 1 includes the master 
node 303 and slave nodes 301, 302 and 304; piconet 4 
includes the master node 305 and slave nodes 304, 306, 307 
and 308; and piconet 5 includes the master node 309 and 
slave nodes 308 and 310. To implement a scatternet it is 
necessary to use nodes which are members of more than one 
piconet. Such nodes are herein referred to as forwarding 
nodes. If, for example, node 301 wishes to communicate 
with node 310, then nodes 304 and 308 might act as 
forwarding nodes by forwarding the information between 
the two piconets and in particular between nodes 301 and 
310. For example, node 301 transfers the information to the 
master node of piconet 1 node 303. Master node 303 
transmits the information to forwarding oode 304. Forward- 
ing node 304 then forwards the information to master node 
305, which in turn, transmits the information to forwarding 
node 308. Forwarding node 308 forwards the infomnadon to 
master node 309 which transmits the information to the 
destination node 310. 

[0024] A Bluetooth device operating within the above- 
described topologies can simultaneously be a slave member 
of multiple piconets, but only master in one piconet. Addi- 
tionally, a Bluetooth device that acts as master in one piconet 
can participate in other piconets as a slave. These various 
roles are reflected in the exemplary topology of FIG, 3 by 
the different shadings used for different Bluetooth devices, 
as indicated by the legend. Since typical Bluetooth devices 
can only transmit and receive data in one piconet at a time, 
participation in multiple piconets can be provided on a time 
division multiplex basis. 

[0025] Each Bluetooth device has a globally unique 48 bit 
IEEE 802 address. This address, called the Bluetooth Device 
Address (BD_ADDR) is assigned when the Bluetooth 
device is manufactured. In addition, the master unit of a 
piconet assigns a local active member address (AM_ADDR) 
to each active member of the piconet. The AM_ADDR, 
which can be, for example, three bits long, is dynamically 
assigned and de- assigned and is unique only within a single 
piconet. The master uses the AM_ADDR when polling a 
slave in a piconet. However, when the slave, triggered by a 
packet from the master addressed with the slave's 
AM_ADDR, transmits a packet to the master, it includes its 
own AM_ADDR (not the master's) in the packet header. 
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[0026] Since ad hoc networks are dynamic, ad hoc net- 
working technology typically has a neighbor discovery 
feature. The neighbor discovery feature allows one Blue- 
tooth unit to find any other Bluetooth unit which the first 
Bluetooth unit can communicate with and consequently 
form an ad hoc network with. A neighbor discovery proce- 
dure in Bluetooth is known as the INQUIRY procedure. 
Once a Bluetooth unit knows of neighboring Bluetooth 
units, a Bluetooth unit can connect to the neighboring 
Bluetooth unit using the PAGE procedure. 

[0027] FIG. 4 illustrates a Bluetooth packet which is used 
for transmitting information, for example within the topolo- 
gies of FIGS. 1-3. The illustrated Bluetooth packet consists 
of access code 410, header 420 and payload 430. The header 
420 contains the AM_ADDR followed by some control 
parameters, e.g., a bit indicating acknowledgment or retrans- 
mission request of the previous packet, when applicable, and 
a header error check (HEC). The access code 410 in the 
packet can be of three different types including a channel 
access code (CAC), a device access code (DAC) or an 
inquiry access code (lAC). 

[0028] The channel access code identifies a channel that is 
used in a particular piconet, i.e., in essence the channel 
access code identifies the piconet. Accordingly, all packets 
exchanged within a piconet carry the same channel access 
code. The channel access code is derived from the 
BD_ADDR of the master unit of the piconet. The device 
access code is derived from a BD_ADDR of a particular 
Bluetooth device. The device access code is used for special 
signaling procedures, e.g., the PAGE procediu-e, as will be 
described below. There are two types of inquiry access 
codes, the general inquiry access code (GIAC) and the 
dedicated inquiry access code (DIAQ. The general inquiry 
access code (GIAC), is sent to discover any Bluetooth units 
in the vicinity. The dedicated inquiry access code (DIAC), is 
sent to discover only certain types of Bluetooth units. Each 
individual dedicated inquiry access code is unique to a 
different type of Bluetooth unit. Both the general inquiry 
access code and the dedicated inquiry access code are used 
in the INQUIRY procedure. 

[0029] FIG. 5 illustrates exemplary signaling performed 
between two Bluetooth units for neighbor discovery and 
connection establishment. Note that in FIG. 5, there are two 
column headings labeled "Message." These columns are 
intended to indicate the relative sequencing of transmissions 
between Bluetooth devices. A Bluetooth unit 1 wishing to 
discover neighboring Bluetooth units broadcasts an 
INQUIRY message. A Bluetooth unit issuing an INQUIRY 
message is referred to herein as the "initiator". The initiator 
then waits and listens for INQUIRY RESPONSE messages. 
An INQUIRY message consists of only an inquiry access 
code, i.e. either a GIAC or DIAC. The INQUIRY message 
will be sent repeatedly according to specified timing and 
frequency sequences, e.g., those found in the published 
"Core Specification of the Bluetooth System", vl.OA, Jul. 
26, 1999, the disclosure of which is incorporated here by 
reference. 

[0030] When a neighboring Bluetooth unit, such as Blue- 
tooth unit 2, receives an INQUIRY message directed thereto 
(i.e., either an INQUIRY message with a GIAC or a DIAC 
associated with that device's type or class), Bluetooth unit 2 
responds with an INQUIRY RESPONSE message. The 



INQUIRY RESPONSE message is transmitted as a fre- 
quency hop synchronization (FHS) packet. FIG. 6 illustrates 
an exemplary frequency hop synchronization packet. All 
fields in the FHS packet, except the AM^ADDR field (and 
the undefined field) indicate properties or parameters of the 
Bluetooth unit that sends the FHS packet. The FHS packet 
includes fields for parity bits, lower address part (LAP), scan 
repetition (SR), scan period (SP), upper address part (UAP), 
non-significant address part (NAP), Class of Device, 
AM_ADDR, internal value of the sending unit's clock 
(CLK), and Page Scan Mode. The LAP, UAP and NAP 
together comprise the BD_ADDR of the responding unit. 

[0031] The Class of Device field indicates the class of 
device of the responding Bluetooth unit. For example, a 
class of device might be a fax machine, phone, printer, or 
refrigerator. The CLK field contains the current value of the 
responding Bluetooth unit's internal clock. The SR, SP and 
Page Scan Mode fields are control parameters used during 
the PAGE procedure. The AM_ADDR field can be used to 
assign an AM_ADDR to a Bluetooth unit which is becoming 
a slave in a piconet (i.e. the AM_ADDR is only used when 
the FHS packet is used in the PAGE procedure) and the 
undefined field is reserved for future use. 

[0032] Referring again to FIG, 5, when a Bluetooth unit 
desires to establish a connection with a neighboring Blue- 
tooth unit, the Bluetooth unit sends a PAGE message. 
Messages 3 through 6 constitute the connection procedure, 
or PAGE procedure, A PAGE message (message 3) consists 
of the Device Access Code (DAC), derived from the 
BD_ADDR of the paged Bluetooth unit. A Bluetooth unit, 
e.g., Bluetooth unit 2, receiving a PAGE message including 
its own DAC responds with an identical packet, i.e., a packet 
including only the DAC (message 4) of the paged Bluetooth 
unit (Bluetooth unit 2). The paging Bluetooth unit, i.e., 
Bluetooth unit 1, then replies with an FHS packet (message 
5), including the BD_ADDR of the paging Bluetooth unit 
(Bluetooth unit 1), the current value of the internal clock of 
the paging Bluetooth unit (Bluetooth unit 1), the 
AM_ADDR assigned to the paged Bluetooth unit (Bluetooth 
unit 2) and other parameters. The paged Bluetooth unit 
(Bluetooth unit 2) then responds with its DAC (message 6) 
thereby establishing a connection between the two Bluetooth 
units. If the paging Bluetooth unit aheady was the master of 
a piconet, the paged Bluetooth unit has now joined this 
piconet as a new slave unit. Otherwise, the two Bluetooth 
units have just formed a new piconet with the paging 
Bluetooth unit as the master unit. 

[0033] Even though existing Bluetooth specifications 
describe the mechanisms that can be tised to create piconets 
and form scatternets, the criteria used to determine which 
connections are actually formed to create a specific piconet 
or scatternet are not specified. For example, when multiple 
neighbors are discovered which offer a particular service 
desired by a user of a Bluetooth unit, there is no specified 
mechanism to determine which of the neighbors to connect 
to in order to form an appropriate piconet. Indeed, as 
mentioned above, the mechanism mentioned in the standard 
is to present the user with the neighbors identified via the 
INQUIRY procedure and require that the user manually 
select the neighbor to which connection shall be made. 

[0034] According to exemplary embodiments of the 
present invention, neighbor selection and connection is 
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performed by identifying and evaluating neighboring Blue- 
tooth units within range and creating a candidate list from 
which a neighboring Bluetooth unit can be selected for 
connection. More specifically, as mentioned above, the 
initiator regularly performs an INQUIRY procedure with the 
class of device field in the INQUIRY message having a 
value that is set to the appropriate class for the ser\'ice 
desired by the initiator. This procedure results in a list of all 
Bluetooth devices of the relevant class within range of the 
initiator. An exemplary method for managing Bluetooth 
device lists according to the present invention is depicted in 
FIG, 7. Since this is an ongoing process, for each respond- 
ing Bluetooth device it can first be determined whether that 
device is already in the device list stored in memory (not 
shown) of the initiator at step 700. If this particular device 
is in the initiator's list, then the process can terminate with 
respect to that device as it has already been evaluated and 
ranked with respect to the desired service. Thus the flow will 
loop through block 702 to evaluate the next responding 
Bluetooth device. 

[0035] If, however, the responding Bluetooth device is not 
found in the initiator's device list, then the flow proceeds to 
block 704 wherein a connection is made to that device, and 
an SDP request is sent to that device (step 706). The details 
of SDP messaging per se are specified in the above- incor- 
porated standards specification and, therefore, are not 
repeated here. However, according to this exemplary 
embodiment, the SDP request asks that the responding 
device return further information, i.e., its values for 
attributes from the initiator's profile for the desired service, 
which profile is also stored in memory. These service 
profiles are described in more detail below. At step 708, the 
values of the attributes in the SDP response from the 
Bluetooth device are then compared with the profile to see 
if this device is a candidate, e.g., by determining how weU 
the responding Bluetooth device's attributes match the ini- 
tiator's service profile. If the responding device is identified 
as a candidate, then this responding device will be inserted 
into a candidate list at step 710 (also stored in the initiator's 
memory) based on how well it fulfils the criteria in the 
profile. Regardless of whether the responding device is 
added to the candidate list, it wiU be added to the device list 
so that this part of the process is not repeated for that device 
upon the next INQUIRY message being transmitted by the 
bitiator. 

[0036] As mentioned above, the candidate list is buih by 
comparing the responding devices' relevant attributes with 
those in the initiator's service profile(s) of interest. The 
criteria used in the profile which define a "best" service for 
the user could be of two different kinds. For example, the 
criteria could indicate a relative preference between different 
values for a particular attribute (e.g. "colour is better than 
black and white, but black and white is OK" or "the higher 
the bandwidth provided by the connection the better"). 
Alternatively, the profile criteria coidd provide a specific 
minimum value for an attribute that must be fulfilled in order 
for a responding device to qualify for entry into the candi- 
date list (e.g. "only colour", or "only bandwidth higher than 
x"). The service profile can be generated based on a com- 
bination of several attributes. 

[0037] Thus, according to exemplary embodiments of the 
present invention, the initiator maintains two lists associated 
with discovered Bluetooth devices. Specifically, one unor- 



dered list which tracks discovered Bluetooth devices (the 
device list) and one ordered list of candidate devices (the 
candidate list), which list is ordered based on how well they 
match the initiator's service profile. Each entry in the device 
list can include, for example, the following information: the 
hardware address of the Bluetooth device (used as identifier 
of the device and to establish a connection thereto), any 
other information needed to establish a connection and 
whether the device is a candidate or not. Each entry in the 
candidate list can include the following information: the 
hardware address of the candidate Bluetooth device, how 
well it matches the relevant service profile and whether this 
Bluetooth device is the servicing device, i.e., the device to 
which the initiator is currently connected to provide a 
particular service, 

[0038] The candidate which is the first on the list, i.e., the 
"best" candidate, can be used for that service, but only when 
that service is needed. Those skilled in the art wiU appreciate 
that this selection process can be run in the background by 
the initiator even if the service is not currently desired. In 
this way, when an application running on the initiator's 
device requests that service, the list of candidates is estab- 
lished and access to a service is faster. 

[0039] Since the initiator is operating in a changing, ad 
hoc environment, it is anticipated that the device and can- 
didate lists will be changing. For example, if a newly 
identified candidate is better than the current servicing 
device, it will be placed first in the list, and used as the new 
servicing device. Additionally, if the initiator detects a link 
failure to the servicing device, it can try to connect to that 
device again. If that fails, this device is removed from the 
candidate list and the device list, thereby forcing a change to 
a new servicing device. 

[0040] Additionally, it may be the case that a device has 
moved out of range or been tm^ned off since it was discov- 
ered. This could result in a scenario wherein a candidate is 
not available when the initiator wishes to connect thereto as 
the new servicing device. In that case this device can be 
removed from both lists, and the next candidate in the list 
can be tried until a connection is successfully made. 

[0041] To further understand these various aspects of the 
present invention, consider the following example which 
follows the signalling diagram depicted in FIGS. S(a) and 
S(b), Consider, for the purposes of this example, that a 
Bluetooth enabled PDA is configured to provide, as one of 
its programmed service access options, Internet access. For 
this example, the user has entered a service profile which is 
simply "the higher the bandwidth, the better". Also assume 
for this example that three devices in within range of this 
Bluetooth enabled PDA offer Internet access. Specifically, 
device A is a Bluetooth enabled mobile phone, which offers 
a low bandwidth connection of x kbps. Devices B and C are 
Bluetooth access points connected to a fixed infirastructure 
which offer a higher bandwidth of y kbps. When the PDA is 
turned on, the search for best access starts in the background 
with devices A, B and C within range. 

[0042] Thus, at Tl in FIG. 8(a), the PDA (acting as the 
initiator) sends out an INQUIRY message and has an empty 
device and candidate list. At T2, the initiator has received 
INQUIRY RESPONSES from the devices within its range 
that offer the desired service, in this example Internet access. 
Thus the device list now contains information associated 
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with devices A, B and C. Next, at T3, the iaitiator connects 
to device A to learn more about its Internet service offering 
via SDP messaging. Device A is added to the candidate list 
since there is no minimum bandwidth criterion in the service 
profile. At T4 and T5, the PDA also interrogates devices B 
and C, respectively, to learn about their Internet access 
characteristics, in this example bandwidth. Thus, at T5, the 
candidate list places devices B and C ahead of device A since 
they offer higher bandwidth Internet connections. 

[0043] Through point T5 in this example, the operation 
has occurred in the background since Internet access had not 
been requested by the PDA's user. However, at T6 (FIG. 
S(by), the user of the PDA decides that he or she actually 
wants to access the Internet, at which time the PDA connects 
to device B since that device is listed first in the candidate 
list. While the PDA is connected to the Internet, the evalu- 
ation of potential service providers continues as a back- 
ground activity. Thus, at T7, the PDA transmits another 
INQUIRY message. During the time between the two 
INQUIRY messages, the PDA has moved out of range of 
device C. Therefore, at T8, the PDA receives INQUIRY 
RESPONSE messages from only devices A and B. Next, at 
T9, the PDA moves out of range of device B and, accord- 
ingly, tries to reconnect thereto. Failing to reconnect to 
device B, the initiator removes device B from both its 
candidate and device list and tries to. connect to the next 
device in the candidate list, i.e., device C at TIO. Since the 
PDA has also moved out of range of device C, this attempt 
at connection also fails leading to the connection to device 
A at Til. 

[0044] Various modifications and adaptations to these con- 
cepts can be adopted. For example, the number of stale 
entries in the candidate list can be minimized if a counter is 
added to each entry in the device list. When a device is first 
discovered and placed in the device list, this counter is set 
to a predetermined value x. Each time an INQUIRY is made, 
and this device does not answer, the counter is decremented. 
Each time an INQUIRY is made, and the device answers, the 
counter is reset to x again. When the counter reaches zero, 
this means that the device has missed x number of sequential 
inquiries. It can then be assumed that the device is no longer 
viable for connection with the initiator and this device is 
removed from the device list and the candidate list (if it was 
a candidate). Since maintenance of the device list is intended 
to avoid having to send SDP requests to the same devices 
multiple times, removal of a device from the list creates the 
downside potential that, if that device appears again, a new 
SDP request has to be made. Thus, the counter value can be 
selected as desired to balance the tradeoff between keeping 
the device list manageably short without having to fre- 
quendy replicate SDP requests for Bluetooth devices that 
move on and ofE the device list. To further optimize this 
tradeoff, devices that are known to be used often can be 
specially marked to be kept in the list even if they don't 
answer inquiries. 

[0045] If the service profile is changed, the candidate list 
can be emptied, and new SDP requests made to all devices 
in the device list, so that the attributes can be compared with 
the new profile and a new candidate list can be built. This 
step could be avoided if the device list also retains attributes 
and their values for each device within proximity of the 
initiator. In this case no SDP requests have to be made to 
build the new candidate list. Then a changed service profile 



only implies a dropped candidate list, which candidate list is 
thereafter built up by checking atu-ibutes in the device list. 
Such implementation alternatives can be selected depending 
upon whether SDP requests (using processing power/bat- 
tery) or storing a lot of data in the device list is a limiting 
factor in the initiator device. 

[0046] Although the present invention is intended to oper- 
ate to identify devices in range of an initiating device to find 
the **best" service access, those devices that are "within 
range" may include devices which are physically out of the 
transmitting range of the initiator but are connected to a 
device which is in range of the initiator. Consider again the 
scattcrnet of FIG. 3. If an initiator comes into range of 
devices associated with piconet 6 and transmits thereto an 
INQUIRY message with a class of device parameter that is 
not available within piconet 6, such an INQUIRY message 
may be forwarded to the other piconets in the scatter net If 
a device within the scat te met corresponds to the class of 
device parameter and can provide the desired service, such 
an indication can be forwarded back through the scatteraet 
to piconet 6 for the transmission of an afiSrmative INQUIRY 
RESPONSE message. This process may be transparent to 
the initiator. 

[0047] Additionally, the present invention can also be used 
in conjunction with selective network access techniques and 
systems as described in U.S. patent application Ser. No, 
09/438,431, entitled "Method and i^paratus for Selective 
Network Access" filed on Nov, 12, 1999, the disclosure of 
which is incorporated here by reference. Therein, methods 
and apparatus for providing selective access to a network, 
for example by linking an end device to the network via an 
access network using a network terminating device are 
described. The end device may (or may not) have a direct 
interface usable for data and/or voice communications. The 
end device is equipped with an indirect interface and uses 
the indirect interface to determine the access capability for 
each access network which is available to the end device. 
The access capabilities may include, for example, cost of 
access, coverage area, available bandwidth, delay and QoS. 
The determined access capability for each access network 
can be compared with a preferred access capability associ- 
ated with the end device, or user thereof, wherein a particu- 
lar access network can be selected based on, for example, 
how favorably the determined access capabilities of each 
access network compare with the prefenred capabilities of 
the end device or user. Accordingly the prefenred capabilities 
may also include cost of access, coverage area, available 
bandwidth, delay and QoS and both the actual access 
network terminating device capabilities and the preferred 
capabilities may include other factors such as the network 
type and the like. Based on the comparison, one of the access 
network terminating devices may be selected and the end 
device may be configured according to the access capabili- 
ties of the selected access network terminating device prior 
to connecting to the selected access network. 

[0048] The indirect interface may be also be used during 
the connection between the end device and the ultimate 
network to detect if new access network terminating devices 
are available to the end device. If new devices are detected, 
an access capabiHty associated with each of the new access 
network terminating devices may be determined and a 
comparison may be made between the determined access 
capabiUty associated with each new access network termi- 
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Dating device, the capabilities associated with the currently 
used access network terminating device and a preferred 
access capability associated with the end device. As in the 
previous embodiment, a decision to reselect among the 
available access network terminating devices is based on the 
comparison. If a better access for the end device is identified, 
the new access network terminating device is selected and 
the end device may be reconfigured according to the access 
capability associated with the selected new access network 
terminating device. 

[0049] Those skilled in the art will appreciate that the 
foregoing techniques and structures can be implemented, for 
example, in a handheld device having a transmitter, a 
processor and a memory device, which components (and 
their programming) will be familiar to those skilled in the 
art. The transmitter, processor and memory device can, for 
example, be configured to operate using communication 
protocols such as those described in the above -incorporated 
by reference documents or other protocols. 

[0050] Thus, it can be seen that these exemplary embodi- 
ments are merely illustrative and should not be considered 
restrictive in any way. The scope of the invention is given by 
the appended claims, rather than the preceding description, 
and all variations and equivalents which fall within the range 
of the claims are intended to be embraced therein. 

What is claimed is: 

1. A method for selecting a device for a service connection 
with an initiating device comprising the steps of: 

transmitting an inquiry message requesting a response 
from devices which receive said inquiry message that 
are within a desired class; 

identifying proximate devices within said desired class 
based on responses to said inquiry message; 

querying said identified devices to obtain al least one 
attribute value associated with a particular service; 

comparing, for each said identified device, said at least 
one attribute value with a profile associated with said 
particular service; and 

selecting one of said identified devices based on said 
comparing step. 

2. The method of claim 1, further comprising the step of: 

storing said profile in a memory of said initiator device. 

3. The method of claim 1, wherein said devices are 
enabled for short range radio communication. 

4. The method of claim 3, wherein said step of querying 
further comprises the step of: 

sending an SDP request to said identified devices. 

5. The method of claim 1, further comprising the steps of: 

determining, prior to said querying step, whether an 
identified device is present in a device list stored in said 
initiating device; and 

selectively querying said identified device based on a 
result of said determining step. 

6. The method of claim 1, further comprising the step of: 

selectively adding said identified devices to a candidate 
li^ based on a result of said comparing step. 



7. The method of claim 5, wherein said device list 
includes for each device therein, at least one of: 

a hardware address of said device and an indication of 
whether said device is present in a candidate Hst. 

8. The method of claim 7, wherein said device list further 
includes said at least one attribute value for each device 
listed therein. 

9. The method of claim 1, further comprising the steps of: 

storing, in a device list, a device which responds to said 
inquiry message; 

initializing a counter for said device; 

decrementing said counter if said device fails to respond 
to a subsequent inquiry message; and 

removing said device from said device list if said counter 
reaches a predetermined value. 

10. A method for selectively accessing a network device 
to provide a service comprising the step of: 

maintaining a ranked candidate list of network devices, 
which each have a matching value associated therewith 
based on a correspondence between a service profile of 
an initiating device and at least one corresponding 
attribute of said network device; 

selecting a highest ranked one of said network devices in 
said candidate list to provide said service; and 

periodically updating said candidate hst to add new 
network devices and remove old network devices. 

11. The method of claim 10, wherein said step of peri- 
odically updating further comprises the steps of: 

transmitting an inquiry message; and 

updating said candidate list based on responses thereto. 

12. The method of claim 11, further comprising the steps 

of: 

deleting, from said candidate list, a network device that 
does not respond to a predetermined number of inquiry 
messages. 

13. A device comprising: 

a transmitter for transmitting an inquiry message request- 
ing a response from devices which receive said inquiry 
message that are within a desired class; 

a processor for identifying proximate devices within said 
desired class based on responses to said inquiry mes- 
sage; 

wherein said transmitter sends another message querying 
said identified devices to obtain at least one attribute 
value associated with a particular service; 

wherein said processor compares, for each said identified 
device, said at least one attribute value with a profile 
associated with said particular service; and selects one 
of said identified devices based on said comparison for 
connecting said device thereto. 

14. The device of claim 13, further comprising: 

a memory unit for storing said profile. 

15. The device of claim 13, wherein said transmitter is 
enabled for short range radio communication. 

16. The device of claim 15, wherein said another message 
is an SDP request. 
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17. The device of claim 13, wherein said processor further 
performs the functions of: 

detennining, prior to said querying step, whether an 
identified device is present in a device list stored in said 
device; and 

selectively querying said identified device based on a 
result of said determining step. 

18. The device of claim 13, wherein said processor further 
performs the function of: 

selectively adding said identified devices to a candidate 
list based on a result of said comparison. 

19. The device of claim 17, wherein said device list 
includes, for each device therein, at least one of: 

a hardware address of said device and an indication of 
whether said device is present in a candidate list. 

20. The device of claim 19, wherein said device list 
further includes said at least one attribute value for each 
device listed therein. 

21. The device of claim 13, further comprising: 

a counter for an associated device in said device list; 

wherein said processor decrements said counter if said 
associated device fails to respond to a subsequent 
inquiry message; and 

wherein said processor removes said device from said 
device list if said counter reaches a predetermined 
value. 



22. A device for selectively accessing a network device to 
provide a service comprising: 

means for maintaining a ranked candidate list of network 
devices, which each have a matching value associated 
therewith based on a correspondence between a service 
profile of an initiating device and at least one corre- 
sponding attribute of said network device; 

means for selecting a highest ranked one of said network 
devices in said candidate hst to provide said service; 
and 

means for periodically updating said candidate list to add 
new network devices and remove old network devices. 

23. The device of claim 22, wherein said means for 
periodically updating further comprises: 

means for transmitting an inquiry message; and 

means for updating said candidate list based on responses 
thereto. 

24. The device of claim 22, further comprising: 

means for deleting, from said candidate list, a network 
device that does not respond to a predetermined num- 
ber of inquiry messages. 

)it if * « * 
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